SAP eCommerce is a challenge if your solution doesn’t include ERP integration out of the box. Many manufacturers come to us after getting burned by vendors who promise comprehensive integration but can’t actually deliver it.

This is why the Corevist Platform includes deep, prebuilt integration to SAP.

But how deep is that integration?

Here’s one small example of how we cover all possible bases.  

The problem: SAP enables security on first PDF printing

Under rare conditions, an SAP web application may give the user a non-printable PDF order document.

We can file this under “odd, but true.” 😊

It’s a surprising, little-known SAP fact: In the context of a web application accessing SAP, under rare conditions, the standard SAP printing program may create a PDF which the user can’t print.

SAP’s standard printing program has some assumptions baked into it. The program assumes that the first time a document output is generated, that output PDF should have security enabled. This prevents the PDF from being edited—but it may also prevent printing.

If you’re offering self-service account management in your web portal, this is not a great user experience.  

Why is SAP’s standard printing program set up like this?

We’ve hunted high and low, and we honestly can’t find an answer. Perhaps the thinking is that original documents should live in a digital-only format, or that any printing action should be viewed as a “reprint” of a digital original that can never be printed.

Whatever the design thinking was behind this feature, it occasionally causes problems for manufacturers with SAP-integrated web portals. If the manufacturer’s processes are such that the PDF generated in the web portal counts as the “original,” SAP will output a non-printable PDF to the user in the web portal.

Conditions under which the user may get a non-printable PDF

Realistically, most manufacturers won’t encounter this problem. Three conditions must be met for this to happen:

1. The SAP printing program supports PDF export.

2. A web application like the Corevist Platform is exposing PDF reviews of SAP outputs.

3. The document you’re printing is an “original” in SAP’s eyes and was never printed before.

Here’s how #3 works. If you print out the invoice and mail it to the customer, and the customer later views the PDF version in the portal, the view in the portal is a “reprint” because the printing action for the mailed document counts as “original.” In this case, the PDF which the user accesses in the portal won’t have security enabled because it’s a “reprint.”

If, however, the document has never been printed out before, and the other two conditions are met, the customer may encounter a PDF in the portal which has security enabled.

This is one of those SAP oddities which even career professionals may never encounter. Though it’s a rare case, it can happen to real manufacturers. Any vendor creating SAP-integrated customer portals or B2B eCommerce needs to take this possibility into account.

Our solution: We’ll help you fix this in SAP

The Corevist Platform doesn’t duplicate SAP data or business rules. It merely presents them to the web user in real time. This means that the problem can’t be resolved with a code change in Corevist. Rather, it requires working around this standard SAP ERP system behavior.

Specifically, these are the lines of code causing this behavior:

If it’s possible that users will access “original” exports of PDFs in your Corevist portal, we’ll need to work around this code so the original PDF is printable.

We can guide you on how to do this—just let us know.

The Takeaway: SAP eCommerce integration requires dedicated experts

While this is a rare use case from the “SAP curiosity” files, it’s worth pointing out one thing: We know about this problem because we live and breathe SAP eCommerce. Because we only work with SAP ERP, we maintain a deep domain expertise which few vendors can replicate. This helps our clients run powerful, SAP-integrated web channels that process over $1.6 billion total in annual order value.